In the modern information society, with the development of information and communication technology, a user can receive and send information, and can execute applications in a terminal device through the device, anytime and anywhere. The data exchange and results of executing the applications need to be stored in the terminal device, and need to be kept consistent with the data of the same type in other terminal devices. For example, address books are saved in a mobile phone and a personal digital assistant (PDA), and the same address books are also saved in a personal computer (PC) or laptop at home or in the office. A user desires that information of the address books in the terminal devices is kept consistent, and once the data saved in any one of the devices is changed, the data in other devices should be changed accordingly. This process is referred to as data synchronization.
The objective of a universal data synchronization protocol is to be universally applicable, that is, both parties of the synchronization may be network devices of any type on any network, such as a handheld computer, a PDA, a mobile phone, an automatic computer, or a PC, and the data to be synchronized may be network data of any type. The synchronization markup language (SyncML) protocol is a universal standard designed to achieve the objective.
The SyncML protocol is a protocol set, which includes four parts, namely, the framework of the SyncML data synchronization protocol, the SyncML synchronization protocol, the SyncML representation protocol, and the SyncML transmission mode. The SyncML synchronization protocol defines the data processes in sessions of data synchronization operation, the handshake process between two parties of the synchronization, and types of data synchronization operation. The SyncML representation protocol describes data types supported in the synchronization, command formats, and SyncML message formats capable of being transmitted on various networks. A SyncML message can be transmitted on any wired or wireless network connection. The SyncML transmission mode defines that SyncML packets and messages can be transmitted on network connections based on the Hyper-Text Transfer Protocol (HTTP), the Wireless Session Protocol (WSP), and the Object Exchange Protocol (OBEX). The three transmission protocols cover most remote and shot-path connections. FIG. 1 is a structural view of the framework of the SyncML data synchronization protocol in the conventional art. In FIG. 1, the frame circled by dashed lines indicates the SyncML framework of the SyncML standard, and the blocks outside the frame circled by the dashed lines indicate the data synchronization protocol. The SyncML framework includes SyncML data formats, SyncML adapters, and SyncML functional interfaces.
In FIG. 1, an application A represents a network service, which is in data synchronization and exchange with some applications of other network devices, for example, an application B in FIG. 1. Public network connections such as HTTP, WSP, and OBEX may be used for a service of a data synchronization (DS) action between the application A and the application B. A “synchronization engine” is in charge of managing actions of the entire synchronization data. The DS action of the application A is based on a DS protocol and the “synchronization engine” is in charge of managing the entire action process. A “synchronization service agent” manages access of the “synchronization engine” to the network and mutual communication processes for the DS of applications on a client and a server. The “synchronization service agent” accomplishes the functions by invoking the “SyncML interface” or functions on the interface. The “SyncML interface” is an application interface for the “SyncML adapter”. The “SyncML adapter” is in charge of processes of receiving and sending messages. In the processes, receiving and sending parties communicate with each other by receiving and sending SyncML format documents. The “SyncML adapter” creates and maintains a network connection between the application A and the application B at the same time. By invoking the functions of the “SyncML interface”, the application B uses a “synchronization client agent” to access the network and its “SyncML adapter”.
As can be seen from the foregoing description, in the SyncML protocol, DS is performed between each SyncML client requiring DS and the same SyncML server, thereby implementing the DS between respective SyncML clients.
FIG. 2 is a flow chart of DS between a server and a client in a SyncML protocol in the conventional art. As shown in FIG. 2, one SyncML synchronization process generally needs six packages. The synchronization process specifically includes the following steps.
In step 201, the client sends a synchronization initialization package PKG1 to the server.
No matter which party initiates the synchronization process, the client first sends the synchronization initialization package PKG1 to the server. The PKG1 mainly includes information such as client authentication information and device capability.
In step 202, after receiving the PKG1, the server verifies the client authentication information, and returns a verification result to the client through a synchronization-initialization response package PKG2.
In step 203, the client analyzes synchronization types specified in the PKG2, encapsulates all data in a local database that is changed after the previous synchronization, that is, the data that needs to be synchronized, into a PKG3, and sends the PKG3 to the server.
The data that is changed includes the data that is added, deleted, and replaced. In action logs of a local database, a location of a log after the previous synchronization is usually identified through the log identifier (ID), and the location is usually specified by an “Anchor” term. In such a manner, during next synchronization, data that needs to be synchronized to the server is the information recorded in the log after Anchor. Table 1 describes a format of reference log information.
TABLE 1AnchorLUIDAction1110555Add1111168Replace1112123Delete1113556Add
In Table 1, a local unique ID (LUID) is a unique ID corresponding to a certain piece of data in the terminal database. The value of LUID is assigned by a terminal.
In step 204, after receiving the PKG3, the server executes various action instructions in the PKG3, replaces the data in a corresponding database, and returns an instruction execution status to the client through a PKG4. At the same time, the server also encapsulates all data that is changed after the previous synchronization in its own database in the PKG4 and returns the PKG4 to the client.
In step 205, after receiving the PKG4, the client performs various action instructions in the PKG4, replaces the data in the local database, and returns an instruction execution status to the server through a PKG5.
If the PKG4 received by the client includes an add instruction of adding a data item in the local database, after the client successfully adds new data locally, the client needs to generate corresponding ID mapping information and notify the server of the corresponding ID mapping information through the PKG5.
Because the server database has a large capacity, a unique ID corresponding to a certain piece of data is different from a unique ID corresponding to the same data in the client database. To determine the same data item that needs to be operated by the client and the server, the server also needs to maintain a mapping table for associating the client database and the server database. Table 2 shows such mapping table.
TABLE 2Client DeviceClient Database:LUIDData11Car22Bike33Truck44ShoesServer DeviceServer Database:GUIDData1010101Car2121212Bike3232323Truck4343434ShoesServer Mapping Table:GUIDLUID101010111212121222323232333434343444
In Table 2, a global unique ID (GUID) is a unique ID corresponding to a certain piece of data in the server database and the GUID is distributed by the server.
In step 206, after the server maintains the ID mapping information included in the PKG5 to the mapping table, the server returns a PKG6 to inform a client of an execution status of a maintenance instruction. After the client receives the PKG6, if all status codes in the PKG6 are normal, it indicates that the synchronization is successful, and the process is ended.
In the process shown in FIG. 2, the client and server usually determine whether the data is changed according to the Anchor and the actions that are performed. However, records of the Anchor and performed actions are replaced according to the synchronization command or after completing the modification indication of data. If the communication is interrupted during the process, if no synchronization response message is received, the Anchor and records of the performed actions may not match. This causes that the data that is changed is unable to be determined accurately. Based on such situation, a fingerprint technology emerges. A data item is able to be identified through a data fingerprint. For example, a fingerprint of a data item is obtained by digesting some data item. The fingerprint may be generated by the client only, or generated by the client and the server. The fingerprint is provided for the server to determine whether the data received by the terminal is the same as the data stored in the terminal, and further determine whether the data is changed. This is because that the fingerprints are inconsistent no matter the server or the client modifies the data.
The fingerprint action includes a unidirectional action and a bidirectional action. The unidirectional fingerprint action means that the client calculates and saves the fingerprint and sends the fingerprint to the server at the same time, and the server does not perform fingerprint action and only saves the fingerprint sent by the client. The bidirectional fingerprint action means that both the server and client calculate fingerprints and save separately the calculated fingerprints.
However, in the conventional art, it is mentioned only that the data fingerprint is able to be adapted to determine whether the data is changed, but no solution for implementing DS through the data fingerprint in the DS process is provided.